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ABSTRACT 


The current military reliance on computer networks for operational missions and 
administrative duties makes network stability and security a high priority for military 
units. The rapid rate at which technology changes means that constant and continued 
training is required for the skilled professionals who maintain and secure these computer 
networks. Current training methods are insufficient at representing the complex nature of 
the typical modem military computer network and the continually evolving nature of the 
attacks to networks. The Mapping, Awareness, and Virtualization Network Administrator 
Training Tool (MAVNATT) is a proposed system designed to replicate operational 
computer networks, through virtualization, providing a stable, accurate, and safely 
partitioned training environment that can closely mimic the configuration and 
functionality of any operational network. This research provides a solution for the 
mapping module of the MAVNATT system in the form of an application. During testing, 
we successfully developed network plans, visualized and verified those plans, scanned 
live networks for comparison and validation against those plans, and exported the 
network configurations for import by the MAVNATT awareness and virtualization 
modules. The mapping application was developed on a foundational framework that 
facilitates expansion and increased functionality during future research. 
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I. 


INTRODUCTION 


A. PURPOSE 

Today's military is increasingly reliant on technology and connectivity to conduct 
training, day-to-day operations, and mission execution. Computer networks have become 
ubiquitous at all levels of organization, including the small units that make up the 
foundation of the Marine Corps. These networks are a cornerstone for modem operations 
and communication: they must be secure and robust. The requisite proper maintenance 
and administration of military computer networks is a challenging task, which requires 
continual training to stay abreast with the pace of changing technology and the periodic 
emergence of external threats. 

Due to the inherent nature and complexity of computer networks, variations in 
configuration and topology are commonplace. For this reason, the live networks found at 
the small-unit level often present a unique set of security and administration 
requirements. Training scenarios executed on a live network provide the best opportunity 
for realism and functionality; however, doing so introduces additional risks and the 
potential for operational impact should a network problem arise during training. For this 
reason, network administrators are often required to seek alternative solutions for 
network training and system testing. 

A typical model for network administrator training involves the establishment of a 
small, stand-alone network using physical hardware. Users can adjust settings, introduce 
changes or malicious programs, and conduct network-related simulations and scenarios 
using this training network. The setup and configuration of such networks is laborious, 
and the size and scope of these networks are necessarily limited by available space and 
equipment. Creating an exact working physical replica of a live network that correctly 
mimics traffic and topology is not a viable option. These factors limit the utility of 
training on such networks. 

The Mapping, Awareness, and Virtualization Network Administrator Training 
Tool (MAVNATT) [1] is a proposed system that provides a solution to deficiencies in the 
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current training model. MAVNATT is a tool that allows network administrators to plan 
and validate a network layout, scan a live network to compare configuration settings 
against the plan, monitor the live network for changes or the emergence of potential 
threats, and create a virtualized replica of the network. This virtualized version of 
a network can be used for training and evaluation purposes, allowing network 
administrators to train on an isolated network “virtually” identical to their live network. 

The focus of this thesis is the development of an application that satisfies the 
requirements for the mapping portion of the MAVNATT system. This application 
should provide functionality for network administrators to develop a network plan, 
visualize and verify that plan, scan the live network for comparison and validation, and 
export the network configuration for import and use by the MAVNATT awareness and 
virtualization modules. 

B. SCOPE AND BOUNDARIES 

The mapping application detailed in this thesis is intended to be used as a tool by 
network administrators to accurately and efficiently capture details of their LAN 
configuration and topology. These details can be stored or exported for use in other 
applications within the MAVNATT system. There is a large amount of information 
available to categorize and describe a network, making it necessary to limit the scope of 
and boundaries of mapping efforts. This implementation of the MAVNATT mapping 
application makes the following assumptions: 

• The network administrator using the application has system administrator- 
level privileges for the respective operational network and is able to install 
and execute programs and send traffic over that network. 

• The user has prior knowledge of the network that is to be mapped, 
including the expected configuration and details of individual connected 
devices. 

• Only devices on the local network are to be included in the results of the 
mapping effort. External devices will not be mapped. 

• The mapping application does not consider physical network topology, 
meaning the actual physical location of devices on the network. 
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• Logical and hardware addresses of individual devices on the network are 
static and are not expected to change after their initial assignment. 

• The mapping application provides a snapshot of the current network 
configuration at the time of execution. 

C. THESIS ORGANIZATION 

This thesis is organized into four additional chapters: background, design and 
implementation, testing and evaluation, and conclusion and proposed future work. 

1. Chapter II: Background 

This chapter describes the purpose and characteristics of the proposed 
MAVNATT system along with some defining characteristics and properties of local area 
networks (LANs). Detailed analysis of LAN traffic provides all the information necessary 
to accurately map a network’s topology and catalog individual devices connected to that 
network. The chapter also gives a brief description and analysis of some existing tools 
and programs that can be used to analyze and evaluate relevant network traffic. 

2. Chapter III: Design and Implementation 

This chapter describes the design and implementation of the MAVNATT 
mapping application, as well as the program flow of execution when using it to map a 
network. The program architecture and framework are described in detail, allowing for 
further implementation and adaptation during future research. This object-oriented 
framework allows for the capture and manipulation of all necessary data to accurately 
describe a network, individual attached devices, and the complex relational interaction 
between devices. The program flow of execution is a detailed step-by-step walkthrough 
of the mapping process from start to finish. 

3. Chapter IV: Testing and Evaluation 

This chapter describes testing and evaluation of the mapping application, to 
include results and findings. Individual tests are conducted to evaluate the mapping 
application's ability to represent a planned network while identifying potential errors in 
the respective network plan. Live network scans are conducted on a controlled physical 
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network environment, allowing testing and evaluation of specific network details. The 
network environment is configured to closely resemble a typical topology of networks 
used by small units in the Marine Corps. 

4. Chapter V: Conclusion and Future Work 

The final chapter provides a summary of work conducted in this thesis, its 
findings, and the resulting functionality of the MAVNATT mapping application. 
Suggestions for areas of future work and research allow for continued development, 
integration and implementation of the mapping application, and the MAVNATT system 
as a whole. 
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II. BACKGROUND 


The proper design and configuration of a computer network is a complex task. 
Simple mistakes in configuration files or device settings can lead to network instability, 
unexpected network activity, or the inability to use the network as intended. Verification 
of these settings can be accomplished through analysis of data as it transits the network. 
However, the sheer volume of available data makes manual network verification tedious 
and prone to errors. Automated tools allow network administrators to more easily gather 
and analyze data and develop a picture of the proposed and existing network topology. A 
thorough definition of the term “network topology” further facilitates the proper use of 
available network data to make inferences and conclusions about the layout and 
configuration of that network, including number and role of comprising elements, along 
with their representative data patterns. Once these are properly scoped, we can use 
existing tools to automate traffic analysis and effectively map a network. 

A. MAVNATT 

MAVNATT is a system proposed by Naval Postgraduate School student, Daniel 
McBride [1], which is undergoing continued research and development. McBride 
identified challenges presented to military network administrators when establishing and 
maintaining small-scale networks, such as those found at the individual unit level. Upon 
properly configuring a computer network, the system administrator often forbids any 
changes to that network for fear of disrupting the stable state. This inaccessibility to the 
live network limits options for training scenarios. The current model is to establish a 
separate stand-alone network on which users can introduce problems or scenarios for 
training purposes. 

The MAVNATT system (see Figure 1) allows a user to replicate a live network in 
a virtual environment that can then be used for training. The mapping module provides 
functionality to scan and accurately represent an existing live network and is the focus of 
this thesis. The awareness module provides the network administrator with real-time 
updates of changes and status of the network. The Virtualization module generates a 
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replica of the live network in a virtualized environment. All modules are interconnected 
by the underlying framework, and together they can be used to both monitor the live 
network and provide a realistic training environment. 



Figure 1. Proposed MAVNATT Framework. Source: [1]. 


The MAVNATT model allows for more effective training than the current model, 
as it simulates operation on the actual live network with duplicate configurations and 
settings. The focus of this thesis is the development of the mapping module, which will 
import a proposed network plan, scan the live network, and provide specifications of 
either the planned network or the actual network. The virtualization module can use these 
specifications to create an accurate replica of the network for awareness and training 
purposes. 

B. NETWORK TOPOLOGY AND CHARACTERISTICS 

We define network topology as the collection of information detailing the logical 

layout and configuration of networked devices, including the interconnections between 

those devices (see Figure 2). This collection of information includes amplifying data 

about the networked devices such as hardware details, logical addressing schemes, 
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operating system used, applications in use, and potential user information. Devices such 
as routers, switches, and hubs facilitate forwarding traffic throughout the local network 
and, specific to the routers, beyond. Client devices are the end users and can include 
computers, printers, hand-held devices; essentially any device that can be connected to 
the network to send and receive data. In this thesis, we focus on the topology of LANs. In 
addition to connected devices, the subdivision of the LAN into even smaller subnetworks 
is an important characteristic of network topology and must be given due consideration, 
as it greatly complicates the mapping task. 



A typical LAN topology distributes client devices and locally hosted servers across 
multiple subnets, allowing for greater control of traffic flow. 


Figure 2. Example LAN Configuration. 

It is important to note that we are not concerned with physical topology, meaning 
the physical location of devices and their relative distance to other devices in the 
network. Rather, we are concerned with the logical layout: which routers are connected to 
one another and at what points are clients connected to the network. 
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1. Open Systems Interconnection Reference Model 

The network topology can be derived through careful analysis of existing traffic 
on the network. However, the type and composition of traffic accessible on a LAN varies 
widely depending on the connected devices and the applications executing on those 
devices. The Open Systems Interconnection (OSI) Reference Model is an abstract 
concept of data encapsulation that allows for the transit of data through the internal 
structure of a computer as well as across networks [2]. This layered approach of 
abstraction (see Figure 3) facilitates interfacing between applications and hardware 
without the requirement to design and implement a system from the ground up for each 
new application. The model also allows for the scaling of systems and networks while 
ensuring compatibility between networking entities [2]. While the OSI Model outlines an 
overall concept for the design of networked systems, it does not detail any concrete 
protocols or specifications. These specifics are left to other models that implement the 
OSI Model guidelines. 


r -^ 

Application Layer 

• N/w access to Application e.g. Web Browser 
(IE, Mozilla Firefox, Google Chrome) 

Presentation Layer 

• Type of Data; HTTPS - Encryption Sevices 

Session Layer 

s 

• Starts and Ends session and also keeps them 
isolated. 



1 

Transport Layer 

• Defines Ports and Reliability 

Network Layer 

• Logicalor IP addressing; Determines Best 
path for the destination. 

Data Link Layer 

• Switches 

• MACAddressing 

Physical Layer 
&__ 

• Cable 

• Network InterfaceCards- Electric Signals 


Figure 3. Overview of the OSI Reference Model. Source: [3]. 
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a. 


Physical Layer 


The physical layer describes the physical medium on which data signals are 
actually transmitted. This medium is the underlying architecture of any connected 
network and it is on this layer that raw digital or analogue traffic transits from one node 
to the next. While there can be some information gleaned from this raw data, analysis of 
transmissions on the physical layer is outside of the scope of this thesis. However, the 
actual capture of network traffic requires some attachment to the physical layer by which 
the upper layer information is extracted. This thesis assumes such access is available. 

b. Data Link Layer 

The data link layer is the first layer above the physical layer and it describes how 
individual pieces of hardware encapsulate data before the actual bits are transmitted to 
the next node. Data to be transmitted is grouped into protocol data units called frames and 
encapsulated with header and trailer metadata, allowing devices to determine the next- 
hop destination of the frame and take action accordingly. The device hardware address, a 
globally unique identifying number for a network interface, is included in this metadata 
[4]. The section of a network in which devices can communicate directly with each other 
via the data link layer is referred to as a broadcast domain. The hardware address is 
carried on all frames of traffic within a single broadcast domain only and is not translated 
or transferred when a packet transits through a router to another broadcast domain. This 
localization of the hardware address is a key piece of information that can be used to 
classify network traffic and identify connected devices during analysis. 

c. Network Layer 

The network layer contains valuable information for determining the logical 

topology and layout of a network. Here, frames are encapsulated with more metadata that 

includes information about the logical addressing scheme, most commonly the Internet 

Protocol (IP). Logical addressing allows traffic to be routed across broadcast domains 

and is an important detail of a LAN’s topology, with each device requiring a unique 

logical address in order to send and receive traffic correctly. In-depth information 

regarding the allocation of addresses among routers and hosts is vital to gaining a 
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complete understanding of the network. Knowledge of a subnet allows us to classify 
which hosts are a part of the network and make a determination about how many 
broadcast domains exist. 

Routers use manually or automatically configured routing tables to forward each 
packet to the next hop (egress point of the connected broadcast domain) within a route 
from a source to destination. The range of possible IP addresses is sub-divided and 
allocated across all users of the Internet. Additionally, private IP ranges can be utilized 
within LANs, as defined by Request for Comments (RFC) 1918 [5], though they must 
undergo an address translation before traffic from the LAN can be routed outside of that 
LAN. Every broadcast domain is represented by a single subnet, or subdivision of IP 
addresses. 

For the purposes of this research, we characterize groups of IP addresses (subnets) 
using the Classless Inter-Domain Routing (CIDR) scheme and identify a subnet by its 
subnet address and subnet mask [6]. The subnet address is the first IP address in the range 
allocated for that subnet. The subnet mask is a bit string that delineates which bits in an 
address designate the network and which designate a host, as depicted in Figure 4. Note 
that this bit string is a set of left-justified 1-bits corresponding to the significant bits of the 
address that represent the network, with the remaining bits of the string set to “0,” 
corresponding to the bits that form the unique identified for the entities connected to the 
subnet. Thus, all IP addresses in a single subnet will have the same network bits in the 
address. Given a particular IP address and the subnet scheme, we can determine to which 
broadcast domain the IP address belongs [6]. 
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Figure 4. Example Subnet Addressing Using CIDR Notation. Source: [7]. 


d. Transport Layer 

The physical, data link, and network layers are similar in that they are all involved 
in the actual delivery of data from one node on the network to another. Conversely, the 
session, presentation, and application layers are where data is actually generated [8]. The 
transport layer handles the transition from the upper layers to the lower layers with the 
chief function of managing application data and preparing it for exchange between the 
communicating application entities. Additionally, as incoming data is received from the 
network layer, services running on the transport layer manage forwarding that data to the 
appropriate application. This allows for many applications and services to run on the 
same computer at once with a single network connection. 

e. Application-Level Layers 

Beyond the transport layer are the session, presentation, and application layers. 
These layers are similar in that they all involve the actual generation and representation 
of data. For the purpose of this thesis, we refer to these layers as a single group, called the 
application-level layers. These layers are generally decoupled from the actual act of 
transmitting data on the network, which is handled by the bottom three layers. However, 
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this data, referred to as the payload, is still visible on the network, and it is the reason for 
the traffic in the first place. While the payload usually does not contain network specific 
information, some applications provide functionality for network establishment and 
management, such as routing protocols like Border Gateway Protocol. Analysis of these 
packet payloads can yield an abundance of information about the devices connected to 
the network, adding to our depth of understanding of the topology. 

2. Internet Protocol Suite 

While often referred to as a reference model as well, the IP Suite is the most 
commonly used collection of standards and protocols pertinent to transfer of data 
between networking domains. It was, and continues to be, developed and maintained by 
the Internet Engineering Task Force (IETF) to facilitate consistency across system and 
application developers. These protocols and standards are explicitly applicable for 
functionalities above what the OSI Reference Model identifies as Physical and Data Fink 
Fayer functions (see Figure 5). Protocol specifications are published via RFCs and are 
continually updated to ensure completeness and security of protocols in an evolving 
network community [9]. These protocols are typically implemented by the various 
operating systems installed on the networked devices and hosts. IP and the Transmission 
Control Protocol (TCP) are the most commonly used protocols in the set, and therefore 
the IP Suite is also frequently referred to as the TCP/IP Suite. Payload and header 
information from the packets of some of these protocols provide the necessary 
information to map the topology of a network. 
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Figure 5. OSI Reference Model and the IP Suite Comparison. Source: [10]. 
a. Address Resolution Protocol 


Address Resolution Protocol (ARP) is used by network devices to correlate a 
hardware address to the corresponding logical address for a given device. Most 
commonly, it allows devices to map Media Access Control (MAC) addresses to IP 
addresses. ARP technically operates to support the network layer, but packets do not 
cross over broadcast domains. Primary ARP messages are the ARP Request by which a 
device issues a query for a MAC address correlating to a specific IP address and the ARP 
Reply response from the queried device. The layout of individual data fields within an 
ARP packet is detailed in Figure 6 [11]. Note that the destination layer 3 address is the 
network address (e.g., IP) for which the layer 2 address is required and the destination 
layer 2 address in the query is the layer 2 broadcast address. For networks employing the 
Institute of Electrical and Electronics Engineers protocols, the layer 2 broadcat address is 
48 bits, all ones (i.e., OxFF:EE:FF:EE:EE:EE in hexadecimal format, colons added for 
clarity only). 
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Figure 6. ARP Packet Data Fields. Source: [11]. 


b. Internet Protocol 

IP is the most commonly used protocol for assigning logical addresses to network 
layer devices. The information available in an IPv4 header can be very useful for 
mapping network topology. IPv4 and IPv6 headers differ slightly, and for the purposes of 
this thesis we will investigate IPv4 packets only. The overall structure of the IPv4 packet 
header is shown in Figure 7. Some of the useful fields in the IP header are protocol, 
source, and destination addresses. The protocol field contains the identifier for next layer 
protocol used in the data portion of the IP packet, normally the transport layer protocol, 
although as indicated by Figure 5 and Figure 7, it could be ARP, Internet Control 
Message Protocol (ICMP), or another protocol operating directly on top of IP. This 
information is necessary to determine how to handle the packet at the destination and 
how to decode the encapsulated data. Source and destination addresses are the sender and 
receiver of the packet. These addresses do not change for the life of the packet and 
remain intact as the data transits across broadcast domains [12]. 
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Figure 7. IPv4 Packet Header Data Fields. Source: [13]. 


c. Internet Control Message Protocol 

ICMP is a messaging protocol used to notify network devices that a problem 
occurred while a packet was in transit. Additionally, it is a mechanism to send network- 
related control messages that can be used for diagnostic purposes. ICMP header fields, 
shown in Figure 8, are type, code, and checksum, followed by a four-byte section that 
varies depending on type and code. For error messages, the data section of an ICMP 
packet contains a copy of the IPv4 header for the packet that caused the error, along with 
the first eight bytes of data from the original packet. The entire ICMP packet is then 
encapsulated in a new IPv4 header for proper routing to the intended recipient of the error 
message. 
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Figure 8. ICMP Packet Header Data Fields. Source: [13]. 


Echo request and echo reply packets perform a function commonly referred to as 
a ping, a diagnostic tool in which one device sends a short request for response to a 
remote device. The remote device issues an echo reply. This ping functionality can be 
used to test proper network connectivity and latency between devices. 

The destination unreachable error message is generated either at the end device, 
the last-hop router before that end device, or by a router that does not have a path to the 
destination network. This error is generated in response to a destination port, device, or 
network being unreachable. This functionality is useful for probing a network for the 
existence of a particular device or for scanning a device to determine which ports are 
open [14]. 

d. Transmission Control Protocol 

TCP is a transport-layer protocol that provides for the connection-based transfer 
of data between two networked devices. The TCP header, shown in Figure 9, 
encapsulates the application data [15]. TCP correlates to the transport and session layers 
of the OSI Model with the primary purpose of establishing a host-to-host connection 
between two networked devices. Once this connection is established, the functionality of 
TCP handles such tasks as the detection of data loss, coordination for the retransmission 
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of packets, re-ordering packets that arrive out-of-order, and governing the rate at which 
packets are transmitted over the connection [15]. In doing so, TCP provides reliable data 
transfer by ensuring that packets arrive at the intended recipient. 
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Figure 9. TCP Packet Header Data Fields. Source: [13]. 


The functionality of TCP allows for the decoupling of the protocols that operate at 
the application layer from the specific details of actually reliably exchanging data over 
the network. Additionally, TCP’s use of stream sockets to establish these host-to-host 
connections allows for multiple connections to be active on the same device at once. 

C. EXISTING TOOLS AND RESOURCES 

It is clear that there is an abundance of information available in the data packets 
flowing over a network. The process of extracting this data into meaningful results is 
tedious and must be automated. As discussed by McBride in chapter II, section C, of his 
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thesis [1], there are many publicly available tools that allow network administrators to 
monitor network traffic and conduct manual analysis. The functionality of these tools can 
be leveraged in an all-inclusive program that will allow a user to automatically scan and 
verify a network. Representing the network itself in a succinct manner presents a 
different challenge. A generally accepted practice is to represent a network as a graph: a 
series of vertices and connecting edges. The vertices represent devices on the network 
and the edges represent connections between individual devices. Fortunately, there exist 
programming libraries and markup languages that provide functionality for the storage, 
manipulation, and visualization of a network graph. This thesis focuses on three existing 
tools that provide functionality to scan and analyze network traffic, visualize and 
manipulate the data available, and store the data for later use by other modules within the 
MAVNATT system. 

1. NMap Security Scanner 

The NMap Security Scanner is a comprehensive open-source tool that provides 
functionality for active network traffic analysis and security auditing [13]. It is available 
as a command-line tool or in a graphical user interface for Linux, MAC OS X, and 
Windows operating systems. NMap boasts an extensive service set with more than 
100 command-line options that include host discovery, remote host operating system 
(OS) detection, port scanning, service and application version detection, and firewall 
detection [13]. The tool provides multiple options for output of results, which can be 
parsed easily or formatted into a human-readable form (see Figure 10). 
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starting Nmap 7.01 ( https://nniap.org ) at 2016-03-31 10:15 Pacific Daylight Time 
Nmap scan report for scanme.nmap.org (45.33.32.156) 

Host is up (0.0095s latency). 

Uot shown; 939 filtered ports, 57 closed ports 

PORT STATE SERVICE 

22/tcp open ssh 

80/tcp open http 

5060/tcp open sip 

8080/tcp open http-proxy 

Device type: general purpose 

Running; Linux 3.X|4.X 

OS CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4 
OS details: Linux 3.11 - 4.1 

os detection performed. Please report any incorrect results at https://nmap.org/submit/ . 
fJmap done: 1 IP address (1 host up) scanned in 7.50 seconds 


Notable data includes name to IP address resolution, significant open ports, and candidate 
OS based on fingerprinting techniques. 

Figure 10. Example Output of an NMap Sean on a Remote Host. 


While a complete understanding of all available NMap operations requires 
extensive experience with the tool, the ability to quickly and accurately scan a network 
for mapping purposes can be achieved with a few basic commands [13]: 

• NMap default functionality: Scans can be conducted on individual hosts, 
IP ranges, or entire subnets using CIDR notation, as exemplified below, 
respectively. NMAP checks to see if the host is up, then conducts a scan 
on ports 1-1000 to determine which ports of those are open [13]. 

nmap 192.168.1.1,192.168.1.2 
nmap 192.168.1.1-30 
nmap 192.168.1.0/24 

• Host discovery (-sn): Omit the port scan and only return those hosts that 
are detected [13]. 

nmap -sn 192.168.1.0/24 

• Remote OS detection (-0): NMap maintains an internal database of 
fingerprints based on how different systems respond to TCP/IP probes. 
This tool compares received results to determine a potential OS match 
[13]. 

nmap -0 192.168.1.0/24 

• ARP Scan ( PR): Sends an ARP Request message vice ICMP or other IP 
based probe. This facilitates quicker scanning on LANs, especially those 
that are sparsely populated with hosts. NMap automatically recognizes if a 
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host address is on the same subnet as the local host from which the scan is 
conducted and defaults to the ARP scan [13]. 

nmap -PR 192.168.1.0/24 

• Exclude addresses (-exclude): Scan all hosts on the given subnet or 
address list except those listed in the exclusion list [13]. 

nmap 192.168.1.0/24 --exclude 192.168.1.1 

• Traceroute (—traceroute): Displays additional information about the 
route from the local machine to the remote host, including the IP address 
of each intermediate hop and timing information [13]. 

nmap 192.168.1.1 --traceroute 

These standard commands can be combined or used individually to retrieve 
enough information necessary to derive the topology layout of a LAN along with 
configurations and details of devices on the network. 

2. Java Universal Network/Graph Framework 

The Java Universal Network/Graph (JUNG) Framework is a collection of open- 
source Java libraries that provide functionality for manipulating information represented 
as a network graph. Created by three PhD students at the University of California, Irvine, 
the project has been continually revised and updated since 2003 [16]. The nature of 
computer networks makes JUNG an excellent tool for visualizing the network topology. 
Using the visualization library, we can display a graphical representation of the vertices 
and edges in a network (see Figure 11). Features of the library include functionality for 
labeling graph elements, changing the color, shape, and size of vertices and edges, and 
manipulating the position of graph elements via mouse [17]. Additionally, JUNG 
includes several pre-defined algorithms that automatically determine the position at 
which to draw each graph element, providing a clean display for easy viewing. 

The underlying infrastructure of JUNG permits full customization of the data used 
to represent vertices and edges in a graph. This allows for the creation of custom objects 
that can be used to store all necessary information about network devices such as routers, 
switches and clients. These custom objects can then be set as the graph vertices, with 
connection information stored in custom graph edge objects. 
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Figure 11. Sample Graph Display Using the JUNG 
Visualization Library. Source: [17]. 

A key component of the JUNG functionality is the Transformer interface, which 
allows the user to set or retrieve information stored within the vertex and edge objects 
during runtime. This is done by defining a class implementation of the Transformer 
interface for each necessary task [17]. The defined class conducts a mapping from one 
object to another. In this manner, the Transformer can change the display characteristics 
of the object based on the values of each vertex or edge. The code snippet shown in 
Figure 12 is an example Transformer implementation that dynamically colors a graph 
edge based on the status of the object used to represent that edge. 
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private static class EdgeColor implements Transformer<Edge, Paint> { 
@Override 

public Paint transform(Edge e) { 

switch (e.getStatus ()) { 

case CONFIRMED: 

return Color. GREEN; 
case INCORRECT: 

return Color. YELLOW; 
case UNPLANNED: 

return Color. RED; 
default: //UNKNOWN 

return Color. BLACK; 

} 

} 

} 


This Transformer class maps a Paint object (Color) to an Edge object based on the status 
of the Edge. 

Figure 12. Example JUNG Transformer Implementation. 


3. GraphML File Format 

The GraphML file format is a markup language designed to efficiently represent 
the topology of a network graph, allowing data to be saved for later use via import and 
export operations [18]. Derived from the Extensible Markup Language (XML) [19], 
GraphML uses start and end tags to declare the different components of a graph. Empty 
tags may be used when declaring an element that has no content. Attributes for the 
individual components can be defined within the start tag of the component. Additionally, 
GraphML allows for the storage of data on nodes and edges by defining custom attributes 
of primitive data types. Key components of a GraphML file are: 

• Header: XML version and schema information used to interpret and 
validate the file format. Schema details are listed inside the GraphML start 
tag. The remainder of declarations of the file are nested in the content 
section between the GraphML start and end tags [18]. 

<?xml version="1.0" encoding="UTF-8"?> 

<graphml xmlns=http://graphml.graphdrawing.org/xmlns> 
</graphml> 
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• Graph: The graph itself. An edge default attribute of directed, undirected, 
or mixed must be defined [18]. 

<graph id="Simple Graph" edgedefault="undirected"> 
</graph> 

• Node: A vertex in the graph. A unique identifier must be defined for each 
node. Node declarations are nested in the graph content section [18]. 

<node id="nl"/> 

<node id="n2"/> 

• Edge: An edge between two nodes in the graph. Source and target nodes 
must be defined for each edge. Edge declarations are nested in the graph 
content section [18]. 

<edge source="nl" target="n2"/> 

• Custom Attributes: Custom attributes are declared outside of the graph 
element using the key tag, while values for those attributes can be set for 
individual components within their respective content sections using the 
data tag. Custom attributes have their own attributes of identifier, name, 
type, and domain that are defined inside the start tag of the attribute 
declaration. Finally, a default value can be declared for custom attributes 
[18]. 

<key id="dO" for="node" attr.name="x" attr.type="int"> 
<k;ey id="dl" for="node" attr. name="y " attr. type=" int" > 

<node id="nl"> 

<data key="dO">50</data> 

<data key="dl">100</data> 

</node> 

The network graph shown in Figure 11 can be represented in a very simple 
manner by declaring custom attributes and setting their appropriate values for 
components in the network (see Figure 13). While networks can be succinctly defined 
using the GraphMF file format, there is no default application for reading and displaying 
a graph defined in GraphMF. Implementation is left to the user and can be accomplished 
using open source libraries such as JUNG or other XMF parsing methods. 
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<?xml version="l.0" encoding="UTF-8"?> 

<graphml xmlns="http://graphml.graphdrawing.org/xmlns" 

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://graphml.graphdrawing.org/xmlns 
http://graphml.graphdrawing.org/xmlns/1.0/graphml.xsd"> 

<key id="d0" for="node" attr.name="color" attr.type="string"> 
<default>green</default> 

</key> 

<key id="dl" for="edge" attr.name="name" attr.type="string"/> 
<graph id="Simple Graph View 2" edgedefault="undirected"> 
<node id="nl"/> 

<node id="n2"/> 

<node id="n3"/> 

<edge source="nl" target="n2"/> 

<data key="dl">Edge-A</data> 

<edge source="n2" target="n3"/> 

<data key="dl">Edge-B</data> 

</graph> 

</graphml> 


Figure 13. GraphML Representation of the Network Graph Shown in Figure 11. 


D. SUMMARY 

This chapter discussed the format, availability, and flow of data on a LAN, as 
well as some proven methodologies for extracting and using that data to represent the 
topology of the network. Fundamental objectives of a topology mapping application are 
algorithmic analysis of the available data, accurate representation of the network, and a 
user-friendly interface for visualization and verification of the network plan. The 
resources described in this chapter can be leveraged to compose an automated application 
for scanning and visualizing network topology. 


24 




III. DESIGN AND IMPLEMENTATION 


A. APPLICATION DESCRIPTION 

The goal of this thesis is to develop an application for use by network 
professionals with administrative oversight over LANs such as those employed at the 
tactical or small unit level. Key functional points of the application would allow the user 
to import a proposed network plan, verify the plan, scan the live network based on 
expected values, and output results in a succinct and readable manner. This would allow 
the network administrator to accurately represent a network, both planned and actual, in 
order to produce a virtualized replica of the LAN for use in training scenarios. This 
application represents the mapping portion of the proposed MAVNATT system [1]. 

The mapping application was written in Java Standard Edition version 8 using the 
Java Development Kit with Netbeans 8.1 Integrated Development Environment [20]. The 
program employs JUNG libraries [16] to manipulate and visualize the network, and 
NMap [13] to scan the live network. Output of the program can be saved as a human- 
readable text file or as a GraphME [18] file for import and export operations. The 
application was written on a Windows 10 platform and compiled with all external 
libraries and dependencies. This allows the application to run on any operating system, 
provided that Java and NMap are installed on that platform. 

B. OBJECT-ORIENTED FRAMEWORK 

We chose to take an object-oriented programming approach for application 
development. This allowed us to create a framework to represent a network via custom 
data structures which fit our needs of representing specific data points within the 
network, as well as the complicated relational interactions between network entities. 
Additionally, an object-oriented approach allowed us to fully leverage the portability 
provided by the programming environment, removing dependencies on platform-specific 
native data sets. In this thesis, we describe each custom object using the Unified 
Modeling Eanguage (UME) [21]. For brevity, the UME diagrams in this section only 
include key data fields and methods within each object, omitting common methods such 
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as toStringO methods and attribute getters and setters. The complete UML diagram for 
the network framework can be seen in Appendix A. 

1. Interface and Switchinterface Objects 

The Interface object (Figure 14) represents the foundational component of a 
network. Individual devices connect to a live network using a network interface card 
(NIC) and point-to-point connections are from one NIC to another. The Interface fields 
are used to characterize the object and its status on the network. Two Interface objects are 
considered to be equal if they share either the same MAC address or the same IPv4 
address. 


Interface 

String name 
byte[] macAddress 
Inet4Address ipv4Address 
Inet4Address gateway Address 
Subnet subnet 
Status status 

Interface() 

Interface(String, String, String) 

equals(Object) 

getCopyO 


Figure 14. UML Diagram for Interface Object. 


The Switchinterface object (Figure 15) extends the Interface object and is used to 
represent a port on a layer 2 switch. The key distinction is that a layer 2 switch port is 
transparent on the network, without an IPv4 address or MAC address. We identify a 
Switchinterface by the name of the switch to which it belongs and a unique numeric 
identifier. Two Switchinterface objects are considered equal if they have the same switch 
name and unique identifier. 
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Switchinterface 

String switchName 
int portlD 

SwitchInterfaceO 

Switchlnterface(String) 

equals(Object) 

getCopyO 


Figure 15. UML Diagram for Switchinterface Object. 


2. Node Object 

The Node object (Figure 16) is used to represent any physical device on the 
network: router, switch, hub, computer, printer, etc. Each Node maintains a set of 
Interface objects, allowing correct representation of multiple network connections for a 
single device (e.g., routers). The merge() method can be used to combine two Node 
objects. Two Node objects are considered equal if they have the same name or share at 
least one Interface. 


Node 

String name 

Set<Interface> interfaces 
String osName 
String imageFileLocation 
Device type 
Status status 

Node() 

Node(Interface) 

equals(Object) 

getCopyO 

merge(Node) 

setAsUnknownO 


Figure 16. UML Diagram for Node Object. 
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3. Edge Object 

The Edge object (Figure 17) is used to represent a connection between two 
Interfaces. Two Edge objects are considered equal if both represent the same two 
Interface endpoints. 


Edge 

Interface ifacel 
Interface iface2 
Status status 

Edge(Interface, Interface) 
equal s(Object) 
setAsUnknownO 


Figure 17. UME Diagram for Edge Object. 


4. Subnet Object 

The Subnet object (Figure 18) is used to represent a subnet address. It provides 
functionality to determine whether a given IPv4 address is a part of the subnet. Two 
Subnet objects are considered equal if they have the same subnet address and subnet 
mask. The netIDsEqual() method can be used to determine whether two different subnets 
have the same subnet address, indicating a potential error in the subnet allocation scheme. 


Subnet 

Inet4Address netID 
Inet4Address netmask 
String CIDRnotation 

Subnet(String) 

equals(Object) 

netlDsEqual(Object) 

getCopyO 

containsHostAddress(String) 


Figure 18. UME Diagram for Subnet Object. 
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5. 


Status and Device Enumerations 


The Status Enumeration (Figure 19) is used throughout the framework as a 
flagging mechanism for Interfaces, Edges, and Nodes. These flags are used when 
scanning the live network and comparing found results with expected results. Status is 
also used to determine which color to make the entity during visualization. Definitions of 
the individual Status flags are: 

• PLANNED (blue): This entity is represented on the network plan. 

• CONFIRMED (green): This entity was confirmed during the live 
network scan with details matching those represented on the network plan. 

• MISSING (orange): This entity is on the network plan, but was not found 
during the scan of the live network. 

• INCORRECT (yellow): This entity was found during the live network 
scan, but some data discovered for the actual device conflicts with that 
represented on the network plan. 

• UNPLANNED (red): This entity is not represented on the network plan, 
but was discovered during a scan of the live network. 

• UNKNOWN (brown): This entity is represented on the network plan, but 
there was not enough information available during the live network scan 
to make a status determination. 


«enumeration» 

Status 

PLANNED 

CONFIRMED 

MISSING 

INCORRECT 

UNPLANNED 

UNKNOWN 


Figure 19. UME Diagram for Status Enumeration. 


The Device Enumeration (Figure 20) is used to specify the type of physical device 
represented by a Node object. This information is used when visualizing the network and 
when generating a GraphME file for later virtualization. The format of the Device 
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enumeration facilitates easy expansion or modification of device types in future 
implementations. 


«enumeration» 

Device 

ROUTER 

COMPUTER 

SWITCH 

PRINTER 

HUB 

UNKNOWN 


Figure 20. UML Diagram for Device Enumeration. 

6. Network Object 

The Network object (Figure 21) is used to bring all of the objects in the 
framework together. Individual fields track the Nodes, Edges, and Subnets that comprise 
the Network, as well as a mapping from Interfaces to Nodes. Individual methods provide 
functionality for adding Nodes and Edges to the Network, merging two Networks 
together, retrieving specific Nodes and Interfaces based on defining details, and 
converting the Network to a graph for use by the JUNG libraries. Two Network objects 
are considered equal only if they have the same set of Nodes, Edges, and Node-to- 
Interface mapping. 
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Network 

Set<Node> nodes 
Set<Edge> edges 
Map<Interfaee, Node> interfaces 
Set<Subnet> 

Network() 

equals(Object) 

getCopyO 

merge(Network, Network) 

setAsUnknown() 

toGraphO 


Figure 21. UML Diagram for Network Object. 


C. PROGRAM FLOW OF EXECUTION 

Using the framework described in Section B above, we developed an application 
that algorithmically scans a live network and provides results by comparing the 
discovered topology to that of the planned network. The flow of execution for the 
program starts with manual generation of a network plan, visualization of that plan, a live 
network scan with visualization of results, and functionality to store and print results in 
different formats. 

1. Network Plan Generation 

The very first step in the establishment of any computer network is the 
development of a network plan. This is the necessary starting point and requires manual 
planning by the network administrator to determine defining characteristics of the 
network such as overall layout and topology, details of connected devices, logical address 
allocation, and security controls in place. While developing a format for the network 
plan, our primary goal was to represent all necessary entities in a succinct but complete 
manner while still being easy to use and read. A secondary goal was to make the plan as 
simple as possible, without reliance on complex database structures or external tracking 
systems, as the network plan would need to be flattened to a text file to facilitate import 
and parsing into our application. The resulting network plan format shown in Figure 22 

uses XML-style tags to separate sections of the plan, each with information relevant to 
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that network entity. The plan is generated in Microsoft Excel and saved as an .xlsx file 
type. This allows for the creation of a succinct yet detailed plan that can be exported to a 
text file for later parsing. 



r 2 IOS C: \U9er9\M4600\De9)ccop\MAVNATT\REPO\router2.7di 

R3 IOS C:\V9er9\M4€00\De9ktop\HAVNRTT\R£PO\router3.vdi 

Client2 Obuntu C:\W9ers\M4600\De9ktop\MAVNATT\REPO\Ubuntu_l.vdi 


Clients Window9 10 C:\09er9\M4600\De9ktop\MAVNATT\REPO\Window9l0_l .vdi 

Clients Obuntu C:\O9er9\M4600\De9ktop\MAVNATT\REPO\Ubuntu_l.vdi 

Client6 _ Obuntu C;\a9er9\M4600\De9ktop\MAVNATT\REP0\0buntu_l. vdi 

f </lMAGB riLBS> 


Figure 22. Example Network Plan Format. 


Clarification of the network plan sections: 

• <NETWORKS>: This section is used to list all subnets that will comprise 
the FAN in CIDR notation, one per row. 

• <ROUTERS>: This section is used to list all routers on the FAN. Each 
interface on a router must be declared on a separate row, allowing for 
multiple interfaces on the same device. The “Next Hop” column is used to 
identify a physical connection within the network and should represent the 
address of the interface to which this interface is physically connected. 
The name of any switch devices listed as next hop connections must 
exactly match a switch name listed in the <FAYER 2 SWITCHES> 
section. 

• <HOSTS AND CLIENT DEVICES>: Similar to the <ROUTERS> 
section, this section lists all client devices on the network, one interface 
per row. The “Device Type” column is a dropdown menu that provides 
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possible options. This field is used to select an icon for the device during 
visualization. 

• <LAYER 2 SWITCHES>: Any layer 2 switch with connections on the 
network must be listed in this section, one per row. Switch names listed in 
the “Next Hop” column of the previous two sections must exactly match at 
least one switch name listed in this section. 

• <IMAGE FILES>: Primarily for future use when integrating the 
MAVNATT mapping module with the virtualization module, this section 
allows the network administrator to list the OS type and the location of 
virtual machine image files for specific network entities. This data is 
stored on the Node object and can be used to instantiate virtual machines 
of the given type. 

After completion of the network plan, it can be exported as a comma-separated 
values (CSV) file type. This provides the file flattening required to import and parse the 
plan for use in the mapping application. This network plan serves as the expected value 
against which the live network scan results can be compared. Appendix B shows a CSV 
version of the network plan shown in Figure 22. 

2. Network Plan Import and Visualization 

The network plan is created manually, independent of the mapping application. 
The exported CSV file then serves as the starting point for the application, with file 
import being the only option upon startup, via the “Import Network Plan” button. After 
import, the console displays a log (see Figure 23), which reflects progress as the plan is 
parsed and individual objects are created within the network framework as described in 
Chapter III, Section B. Potential problems identified while parsing the network plan are 
displayed in the log as well. This provides the network administrator an opportunity to 
identify mistakes in the plan. 
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Network Mapping Tool — □ X 


Import Network Plan 


Parsing file: Test Lab - Simple.csv 

<lJEr«JORKS> 

Added subnet: 

Added subnet: 

Added subnet: 


cRCnTERS> 


Added 

Interface to 

Node: 



Added 

Interface to 

Node: 



Added 

Interface to 

Node: 



Added 

connection: 




Added 

Interface to 

Node: 



<H0STS AND CLIENT 

DEVICES> 



Added 

Interface to 

Node: 



Added 

Interface to 

Node: 



Added 

Interface to 

Node: 



Added 

Interface to 

Node: 



Added 

Interface to 

Node: 



<LAYER 2 SWIICHES> 




Added 

Interface to 

Node: 



Added 

connection: 




Added 

Interface to 

Node: 



Added 

connection: 




Added 

Interface to 

Node: 



Added 

connection: 




Added 

Interface to 

Node: 



Added 

connection: 




Added 

Interface to 

Node: 



Added 

connection: 




Added 

Interface to 

Node: 



Added 

connection: 




Added 

Interface to 

Node: 



Added 

connection: 




<IMAGE FILES> 




Added 

05 name and 

location 

to 

Node 

Added 

OS name and 

location 

to 

Node 

Added 

OS name and 

location 

to 

Node 

Added 

OS name and 

location 

to 

Node 

Added 

OS name and 

location 

to 

Node 

Added 

OS name and 

location 

to 

Node 


tJetwork plan parsed successfully. 


192.168.0.0/26 

192.168.0.64/26 

192.168.0.208/30 


faO/1 : R2 
faO/0/0 : R2 
faO/1 : R3 

<192.168.0.210 <—> 192.168.0.209> 
faO/0/0 : R3 


ethO : Client2 
ethO : Client3 
ethO : Clients 
ethO : Clients 
ethernet : Printer2 


portO : Switch 1 
<192.168.0.20 <—> Switch 1> 
portl : Switch 1 
<192.168.0.30 <—> Switch 1> 
port2 : Switch 1 
<192.168.0.1 <—> Switch 1> 
ports : Switch 2 
<192.168.0.100 <—> Switch 2> 
port4 : Switch 2 
<192.168.0.90 <—> Switch 2> 
ports : Switch 2 
<192.168.0.80 <—> Switch 2> 
ports : Switch 2 
<192.168.0.6S <—> Switch 2> 


R2 

R3 

Client2 

Clients 

Clients 

Clients 


The application parses each section of the network plan sequentially and displays a 
progress log. Updates are displayed as objects are created within the network framework, 
or when potential problems are identified. 

Figure 23. Import Log After Parsing the Network Plan Shown in Figure 22. 

Upon successful completion of the network plan import, the application 
automatically displays a visualization of the planned network (see Figure 24). This 
provides the network administrator another tool with which he can verify the plan and 
identify any potential problems in the proposed configuration. The network is displayed 

as a graph using the JUNG libraries [16]. Each device is represented by a corresponding 
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icon, with edges of the graph representing physical connections between devices. The 
blue icons in the display indicate that this is the planned network and the status variable 
of each Node, Edge, and Interface object is set to “PLANNED.” 


Test Lab - Simple.csv — □ X 

File Scan 



Eigure 24. Visualization after Parsing the Network Plan Shown in Eigure 22. 

3. Live Network Scan and Visualization 

At this point of the application execution phase, the planned network is stored in 
memory as a Network object according to the object-oriented framework described in 
Chapter III, Section B. Here, the user can scan the live network to detect configuration 
and settings of connected devices. The live network scan is a sequential process using 
bounds established by the planned network, which serves as the expected value against 
which results are compared. Any variation between the planned network and discovered 
results is annotated and displayed. The scan is initiated via the menu bar in the graph 
visualization window by selecting the Scan > Scan Live Network option. This displays a 
new empty console with one available option, the “Start Scan” button. 
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a. Preparation 

The application starts by making a deep copy of the planned network. During this 
process, the status variable of each Node, Edge, and Interface object is set to 
“UNKNOWN.” This process is transparent to the user and facilitates status updates on 
individual network entities as settings are confirmed or found to be invalid. The planned 
network is left intact and this new Network object, referred to as the result network, is 
now the working copy for the live network scan. 

b. Detect Local Host Settings 

In the initial verification step, the application determines the settings for the local 
host on which the mapping application is being executed. Once the local IP address and 
MAC address are determined, the application searches the result network for the 
corresponding Interface object with matching details. Details of the local host are 
displayed to the scan report console (see Figure 25) along with any inconsistencies 
discovered. This identification of the local host provides the application with necessary 
information to conduct a more fine-grained verification of other devices on the same 
subnet, as this is the only scenario when the MAC address of remote devices is visible 
to the mapping application. The status variable for the discovered Interface is set 
accordingly. 
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1^1 Live Network Scanner 


□ X 


Start Sr 


Display Network Graph 


Save Network Details 


Local Host Details: 


▲ 

[lame: 

DESKTOP-CLIENTS 


Type: 

COMPUTER 


Operating System: 

Windows 10 


Status: 

CONFIRMED 


Interface: 

ethl 


IPv4 Address: 

192.168.0.30 


MAC Address: 

C8:1F:66:0F:D6:B9 


Status: 

CONFIRMED 


Found remote host: 



Name: 

Client2 


Type: 

COIPDTER 


Operating System: 

Linux 3.2 - 4.4 


Status: 

CONFIRMED 


Interface: 

ethO 


IPv4 Address: 

192.168.0.20 


MAC Address: 

C8:1F:66:07:0F:1D 


Status: 

CONFIRMED 


Found remote host: 



Name: 

Client6 


Type: 

COMPUTER 


Operating System: 

Linux 3.2 - 4.4 


Status: 

CONFIRMED 


Interface: 

ethO 


IPv4 Address: 

192.168.0.90 


MAC Address: 

C8:1F:66:07:10:7E 


Status: 

CONFIRMED 



Figure 25. Example Scan Report Console Output. 


c. Scan Planned Devices 

At this stage, the application iterates through each Interface object in the result 
network. For those Interfaces with an IP address defined (i.e., not Switchinterface 
objects), the application conducts the following NMap scan, where [IP ADDRESS] is the 
IP address of the current Interface being verified. 

nmap -F -0 —osscan-limit --max-os-tries 1 [IP ADDRESS] 

This NMap scan is executed in a background process and the output is redirected 
to the mapping application where it is parsed. If a host is detected at the given IP address. 
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a parsing function uses regular expressions to extract the IP address, MAC address (if 
present), and potential OS of the host from the NMAP scan report. This data is used to 
verify the details of the expected Interface object and the status variable for the Interface 
is set accordingly. As data is parsed, log messages are displayed to the scan report 
console, as shown in Figure 25, and changes to each Interface in the result network are 
made according to the following criteria: 

• Interfaces on the same subnet as the local host are labeled 
“CONFIRMED” if the discovered IP address and MAC address match 
expected values. 

• Interfaces on the same subnet as the local host are labeled “INCORRECT” 
if the discovered MAC address differs from the expected value. 

• Interfaces on remote subnets are marked “CONEIRMED” if their IP 
address alone matches its expected value. 

• Any status change made to an Interface is also made to the Node object to 
which that Interface belongs. 

• If the NMap scan returns a single potential OS match for the scanned host, 
the Node object to which the Interface belongs is automatically updated to 
reflect the discovered value. 

• If no corresponding host is found via the NMap scan, no action is taken at 
this time. 

After scanning for all Interface objects, the mapping application will rescan for all 
Interfaces in the result network that still have a status of “UNKNOWN,” meaning they 
were not detected on the first attempt. If NMap again fails to locate a host at the given IP 
address, the status variable for the given Interface is set to “MISSING.” The status of any 
Node object with all Interfaces set as “MISSING” is set to “MISSING” as well. If a Node 
has at least one missing Interface and at least one that was detected during the NMap 
scan, the status for that Node is set to “INCORRECT.” 

d. Scan for Unplanned Devices 

After scanning for all expected devices, the mapping application scans the known 
subnets for any device present that is not on the network plan. To do so, the application 
executes the following NMap scan, where [SUBNETS] is a list of all subnets from the 
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planned network and [ADDRESSES] is a list of all IP addresses of Interfaces from the 
planned network. 

nmap -sn [SUBNETS] —exclude [ADDRESSES] 

If an unexpected device is found, the NMap results are parsed for IP address and 
MAC address (if present) using regular expressions. These addresses are used to create 
new Interface and Node objects with the status variable set to “UNPEANNED.” The new 
Node with corresponding Interface are then added to the result network, allowing them to 
be displayed later. 

e. Analyze Network Connections 

Checking the status of the connections in the network to complete the comparison 
between the live network scan results and the expected value required that we make some 
inferences. The layer 2 switch is transparent on the network, making it impossible to scan 
for the existence of specific switch ports. Instead, the application counts the number of 
discovered IP addresses on each subnet. If there are more than two addresses on a given 
subnet, then all connections must be going through a switch or hub. Changes to each 
Edge in the result network are made according to the following criteria: 

• If one endpoint is an Interface with an IP address on a subnet with more 
than two IP addresses present, the other endpoint must be a 
Switchinterface. If the Edge meets this criteria, its status is set to 
“CONEIRMED.” Otherwise, it is set to “INCORRECT.” 

• If one endpoint Interface is marked as “MISSING,” the Edge status is set 
to “MISSING.” 

• If both endpoints are Interfaces with IP addresses on the same subnet, and 
the number of IP addresses present is exactly two, the Edge status is set to 
“CONEIRMED.” 

• At no time is any new Edge object created and added to the result 
network. 

4. Results Output 

Upon completion of the network scan, the application presents several methods to 
view and save the results. As shown in Eigure 25, the user is given options to display the 
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network graph or save the network details. The “Display Network Graph” button shows a 
visualization of the live network sean results (see Figure 26). Nodes and Edges in the 
display are color coded according the status variable for the given object. This provides 
the network administrator with an overview of the network configuration that allows for 
quick identification of potential problems. 


Results of Live Network Scan — □ X 

File 



In this example, all interfaces on all devices have been confirmed by the network scan. 

All connections meet the confirmation criteria. The layer 2 switches maintain a status of 

UNKNOWN. 

Figure 26. Visualization of Live Network Scan Results. 

The “Save Network Details” option allows the user to save a textual 
representation of the live network scan results. Appendix C is the detailed log file for the 
live network scan shown in Figure 26. 

Finally, the user has the option to save a graph representation of a network, either 
planned or actual scan results, as a GraphML file. This is accomplished via the File > 
Save as GraphML option from any network visualization window. 
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D. SUMMARY 


This chapter details the internal structure of the MAVNATT mapping application 
as well as the program flow of execution. The established data structures in the network 
framework allow for extensibility and future development. Additional data fields can be 
added to individual object types without disrupting the relational interaction between 
each object within the framework, allowing for finer granularity of details of connected 
devices. The program flow of execution allows the network administrator to visualize a 
proposed network plan and quickly identify potential problems. Similarly, the available 
output options of a live network scan allow the user to easily identify conflicts between 
the planned network and actual results. This functionality facilitates network 
configuration troubleshooting and identification of potential problems or threats to the 
network. Finally, the ability to export displayed networks as a GraphML file facilitates 
the virtualization of any network, either planned or actual, via the virtualization portion 
of the MAVNATT system. 
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IV. TESTING AND EVALUATION 


A. OVERVIEW OF TESTING 

We focused testing efforts on the two primary functions for the mapping 
application: correct validation of the network plan, and accurate scanning of the live 
network. To do so, we established a physical test network environment for use while 
evaluating the live network scan functionality of the application. We then generated 
different versions of a network plan, each representing this test network. Variations in 
these network plan versions created specific scenarios that allowed us to test individual 
sources of potential errors in the mapping application. 

B. TEST NETWORK ENVIRONMENT 

For consistency and controlled variability during network scanning, we 
established a test network environment with physical hardware similar to that used by 
Marine Corps units on LANs. The network consisted of five Cisco 2811 routers, two 
Cisco 1900 series layer 2 switches, six client computers and a server computer (see 
Figure 27). The routers were configured using the Enhanced Interior Gateway Routing 
Protocol. Five of the client computers were loaded with the Ubuntu version 14.04 OS and 
the sixth (Clients) was loaded with Windows 10. The server computer was configured as 
both a Domain Name System (DNS) server and a web server on the Ubuntu 14.04 OS. 
Scripts running on all six client computers were used to conduct periodic DNS queries 
and to request pages from the web server. These scripts generated a steady flow of traffic 
and provided a more realistic network scenario. 
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Figure 27. Test Network Environment Configuration. 

C. TEST NETWORK PLANS AND CONFIGURATIONS 

We generated four variations of the network plan representing the test network 
environment. Each variation was designed to test key functional points of the mapping 
application by forcing errors that would then be annotated by the application. Eor brevity, 
the image file details for each networked device were omitted from network plans during 
testing. These details are only relevant for later use within the overall MAVNATT 
framework. The complete network plan used for each test scenario can be found in 
Appendix D through Appendix G. 
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1 


Control Configuration 


The control configuration network plan (see Appendix D) accurately reflects the 
actual configuration of the test network shown in Figure 27. Each networked device is 
correctly represented with its corresponding IP address, MAC address, and next-hop 
connection. The subnet allocation scheme is valid and all subnets are properly 
represented on the plan. After importing the network plan, the parse log (see Figure 28) 
shows no indication of any potential problems. 


i4h Network Mapping Tool — □ X 


Import Network Plan 


<ROaTERS> 



A 

lidded 

Interface to 

Node: 

faO/0 : R1 


lidded 

Interface to 

Node: 

faO/1 : R1 


lidded 

Interface to 

Node: 

faO/0/0 : R1 


Udded 

Interface to 

Node: 

faO/0 : R2 


lidded 

Interface to 

Node: 

faO/1 : R2 


Udded 

Interface to 

Node: 

faO/0/0 : R2 


Uded 

Interface to 

Node: 

faO/0 : R3 


Udded 

connection: 


<192.168.0.202 <—> 192.168.0.201> 


Udded 

Interface to 

Node: 

faO/1 : R3 


Udded 

connection: 


<192.168.0.210 <“> 192.168.0.209> 


Udded 

Interface to 

Node: 

faO/0/0 : R3 


Udded 

Interface to 

Node: 

faO/0 : R4 


Udded 

Interface to 

Node: 

faO/1 : R4 


Udded 

connection: 


<192.168.0.218 <—> 192.168.0.217> 


Udded 

Interface to 

Node: 

faO/0 : R5 


Udded 

connection: 


<192.168.0.205 <—> 192.168.0.206> 


Udded 

Interface to 

Node: 

faO/1 : R5 


Udded 

connection: 


<192.168.0.214 <--> 192.168.0.213> 


CHOSTS AND CLIENT DEVICES> 



Udded 

Interface to 

Node: 

ethO : Clientl 


kdded 

Interface to 

Node: 

ethO : Client2 


Udded 

Interface to 

Node: 

ethO : Client3 


Udded 

Interface to 

Node: 

ethO : Client4 


Udded 

Interface to 

Node: 

ethO : Clients 


Uded 

Interface to 

Node: 

echo : Clients 


Udded 

Interface to 

Node: 

: Printer2 


Udded 

Interface to 

Node: 

echo : Neb Server 


Udded 

connection: 


<192.168.0.130 <—> 192.168.0.129> 


cUYER 2 SHITCHES> 




Udded 

Interface to 

Node: 

portO ; Switch 1 


Udded 

connection: 


<192.168.0.20 <--> Switch 1> 


Added 

Interface to 

Node: 

portl : Switch 1 


Added 

connection: 


<192.168.0.10 <—> Switch 1> 


Added 

Interface to 

Node: 

port2 : Switch 1 


Added 

connection: 


<192.168.0.30 <—> Switch 1> 


Added 

Interface to 

Node: 

port3 : Switch 1 


Added 

connection: 


<192.168.0.1 <“> Switch 1> 


Added 

Interface to 

Node: 

port4 : Switch 2 


Added 

connection: 


<192.168.0.100 <—> Switch 2> 


Added 

Interface to 

Node: 

ports : Switch 2 


Added 

connection: 


<192.168.0.70 <—> Switch 2> 


Added 

Interface to 

Node: 

ports : Switch 2 


Added 

connection: 


<192.168.0.90 <—> Switch 2> 


Added 

Interface to 

Node: 

port7 : Switch 2 


Added 

connection: 


<192.168.0.80 <—> Switch 2> 


Added 

Interface to 

Node: 

ports : Switch 2 


Added 

connection: 


<192.168.0.65 <--> Switch 2> 


cIMAGE FILES> 




iletwork plan parsed successfully. 




Figure 28. Control Configuration Network Plan Parse Fog. 


After conducting the scan of the live network, both the network plan visualization 
and the live network scan visualization (see Figure 29) match expectations of the test 
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network configuration. All devices on the network are present with details confirmed 
according to the criteria described in Chapter III, Section C. 


m s««i 


Lm Scan 


□ 


X 




Comparison of the network plan visualization (left) and the live network scan 
visualization (right) shows consistency in results based on the expected value. 


Figure 29. Control Configuration Visualizations. 


2. Invalid Network Plan Testing 

We developed an invalid network plan (see Appendix E) to test the validation and 
visualization of the network plan. Inconsistencies and errors were introduced to the 
plan to test whether the mapping application correctly identified the errors and conveyed 
the details to the user. These errors represent common mistakes made by network 
administrators such as typographic errors, incorrect subnet and IP address allocation, or 
simply misrepresenting the expected configuration in the network plan. The invalid 
network plan contains the following errors: 

• Subnet 192.168.0.212/30 is incorrectly entered as 192.168.0.2122/30, a 
potential typographic error. 

• The next hop address for R3 interface faO/1 is listed as 192.168.0.211 
where it should be 192.168.0.209. The IP address 192.168.0.211 does not 
exist on the network. This error could be the result of incorrect subnet 
calculation or simply swapping potential values on the plan. 

• The next hop address for R3 interface faO/0/0 is listed as Switch 3, but no 
Switch 3 exists on the network. 
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After importing the network plan, the parse log (see Figure 30) correctly displays 
a problem with the invalid subnet 192.168.0.2122/30. This subnet is therefore never 
created within the network framework. Additionally, error messages are reported when 
adding the interfaces with addresses 192.168.0.213 and 192.168.0.214, because no valid 
subnet is found that contains these addresses. 



Figure 30. Invalid Network Plan Parse Log. 


The network plan visualization (see Figure 31) correctly shows that the expected 
connections between R2 and R3, and between R3 and Switch 2 are missing. These 
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inconsistencies provide a cue for the network administrator to review his plan for 
potential errors with these connection settings. 


lii — □ 



Figure 31. Invalid Network Plan Visualization. 

3. Incorrect Network Details Testing 

We developed an incorrect network plan (see Appendix F) to test the live network 
scan functionality of the mapping application. The plan lists incorrect details for some 
devices on the network to test whether the application correctly identified deviations 
between the network plan and the live network and conveyed the details of errors to the 
user. The errors in this test are limited to incorrect MAC addresses and IP addresses for 
interfaces on the network. The incorrect network plan contains the following errors: 

• The next hop address for R3 interface faO/1 is listed as 192.168.0.211 
where it should be 192.168.0.209. 

• The IP address for the Client3 interface is listed as 192.168.0.33 instead of 
the correct value of 192.168.0.30. We ran the mapping application from 
Client3, so this error affects the details of the local host. 
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• The MAC address for the Client2 interface is listed as C8:1F:66:07:0F:1E 
instead of the correct value of C8:1F:66:07:0F:1D. 

• The IP address for the Clients interface is listed as 192.168.0.88 instead of 
the correct value of 192.168.0.80. 

• The MAC address for the Printer2 interface is listed as 00:15:99:D5:5D:33 
instead of the correct value of 00:15:99:D5:5D:34. 

After importing the incorrect network plan, we scanned the live network, 
producing the scan console log output shown in Figure 32. 


Live Network Scanner 


□ 


X 


Sr 


Display Network Graph 


Save Network Details 


Local hosts address is 

192.168.0.30 

.^1 

2ould not find a corresponding Interface in the network plan. 

Scan results niay be affected. 


Local Host Details: 
:iame: 

DESKTOP-CLIENTS 


Type: 

UNKNOWN 


grating System: 

Windows 10 


Status: 

INCORRECT 


Interface: 

ethl 


IPv4 Address: 

192.168.0.30 


MAC Address: 

C8:1F:66:0F:D6:B9 


Status: 

INCORRECT 


'{AC address conflict for interface on local subnet: 192.168.0.20 
Expected: C8:1F:66:07:0F:1E 

Found: C8:1F:66:07:0F:1D 


Found remote host: 
name: 

Client2 


Type: 

C<»{PUTER 


Operating System: 

Linux 3.2 - 4.4 


Status: 

INCORRECT 


Interface: 

ethO 


IPv4 Address: 

192.168.0.20 


MAC Address: 

C8:1F:66:07:0F:1D 


Status: 

INCORRECT 



Figure 32. Incorrect Network Details Scan Log. 


The scan console log correctly annotates the following conflicts: 

• The application identified a local host addressing conflict. The local host 
IP was identified as 192.168.0.30, but there is no interface with a 
corresponding address represented on the network plan. A new Node is 
created to represent the actual local host. 

• The application discovered a host at Client2’s expected IP address, but 
with a MAC address that is not the expected value represented on the 
network plan. This IP address is on the same subnet as the local host, 
making MAC address verification possible. The status of Client2 is set as 
“INCORRECT.” 
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• The application failed to locate any device at IP address 192.168.0.33, so 
the status of Client3 is set to “MISSING.” 

• The application failed to locate any device at IP address 192.168.0.88, so 
the status of Clients is set to “MISSING.” 

• The application discovered an unexpected device at IP address 
192.168.0.80. This is the actual address of Clients. A new Node object is 
created and added to the network to represent the unexpected device. 

The visualizations of the planned network and the live network scan results (see 
Figure 33) reflect the errors annotated in the scan console log. A new Node object with 
the correct values of the local host is added to the network, represented in yellow. Client2 
is yellow to denote the incorrect MAC address. Client3 and Clients are orange to 
represent that they are on the network plan, but were not found during the live network 
scan. A newly discovered device (the actual Clients) is shown in red. Additionally, the 
expected connection between R2 and R3 is again missing, which represents the incorrect 
value given for the next hop destination of R3 interface faO/0/0. This connection actually 
exists on the network but the mapping application has no way to detect or verify it. 


^3 jcjw 


o 


X 



Comparison of the network plan visualization (left) and the live network scan 
visualization (right) shows several discrepancies. 

Figure 33. Incorrect Network Details Visualizations. 
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A notable point in this result is that Printer2 is green and listed as confirmed, even 
though the MAC address was listed incorrectly in the network plan. This is the expected 
behavior of the application. The live network scan was conducted from Clients, on a 
different subnet than Printers. The mapping application has no access to the MAC 
addresses of devices on remote subnets and therefore confirms remote devices by 
matching IP addresses only. 

4. Invalid Network Configuration Testing 

For the final test, we focused on inconsistencies in the test network rather than 
incorrect data entry in the network plan. This test was developed to assess the live 
network scan functionality of the mapping application. In the test, some devices were 
turned off and cables were disconnected. These errors represent device outages or other 
common problems when managing a live network. The network plan itself (see Appendix 
G) is largely the same as the control configuration network plan with a single exception. 
The variations created for this test are as follows: 

• Subnet 192.168.0.208/30 and 192.168.0.12/30 are merged into a single 
subnet: 192.168.0.208/29. Given the intended network configuration, this 
creates an invalid IP addressing scheme because there are multiple 
collision domains using the same subnet. 

• The connection between R1 interface faO/1 and R4 interface faO/1 was 
unplugged. 

• Clients was turned off. 

After importing the invalid configuration network plan, the parse log shows no 
indication of any problems, as expected. We then scanned the live network, producing the 
scan console log output shown in Figure 34. The mapping application correctly identifies 
that R1 interface faO/1 and R4 interface faO/1 are unreachable as a result of the unplugged 
cable. The Edge object representing the connection between these two interfaces has been 
set to “MISSING.” The application also identified that Clients was unreachable, the 
result of that computer being turned off. 
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Live Network Scanner 


□ X 


Display Network Graph 


Save NetvirorK Details 




▲ 

Failed to locate host 

at address: 192.168.0.218 


Failed to locate host 

at address: 192.168.0.80 


Rescanning for missing 

devices. 


Interface is missing: 



tiame: 

R1 


Type: 

Dperating System: 

ROUTER 


Status: 

INCORRECT 


Interface: 

faO/0 


IPv4 Address: 

192.168.0.201 


MAC Address: 

00:15:63:40:83:80 


Status: 

CONFIRMED 


Interface: 

faO/1 


IPv4 Address: 

192.168.0.217 


MAC Address: 

00:15:63:40:83:81 


Status: 

MISSING 


Interface: 

faO/0/0 


IPv4 Address: 

192.168.0.129 


MAC Address: 

54:7S:D0:7C;70:9F 


Status: 

CONFIRMED 


Interface is missing: 



llame: 

R4 


Type: 

Dperating System; 

ROUTER 


Status: 

INCORRECT 


Interface: 

faO/O 


IPv4 Address: 

192.168.0.213 


MAC Address: 

00:18:73:10:27:00 


Status: 

CONFIRMED 


Interface: 

faO/1 


IPv4 Address: 

192.168.0.218 


MAC Address: 

00:18:73:10:27:01 


Status: 

MISSING 



Figure 34. Invalid Network Configuration Scan Log. 


The visualization of the live network scan results (see Figure 35) reflects the 
errors annotated in the scan console log. In addition to identifying the missing device, the 
mapping application correctly identifies and displays errors in the connections between 
devices. The edge representing the connection between R1 interface faO/1 and R4 
interface faO/1 has been set to “MISSING” and is thus colored orange. The edges 
between R2 interface faO/1 and R3 interface faO/1 and between R4 interface faO/0 and R5 
interface faO/1 are both set as “INCORRECT” and colored yellow. This indicates a 
potential problem with the IP addressing scheme where the interfaces on these edges are 
expected to be on the same subnet. This is an invalid network configuration. 
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Figure 35. Invalid Network Configuration Scan Visualization. 

D. SUMMARY 

This chapter details the testing and evaluation conducted on the MAVNATT 
mapping module application. We established a physical test network that closely 
resembles those in use by Marine Corps units to provide a consistent and modifiable 
environment on which to run test scenarios. Four separate network plans and 
configurations were developed to test specific functional points of the mapping 
application. These test scenarios showed that the mapping application functions as 
expected and correctly identifies potential problems in a network plan as well as conflicts 
between the network plan and the actual live network configuration. Results from these 
tests show that the live network scan results combined with the network plan 
visualization provide a useful tool for network administrators to troubleshoot networks. 
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V. CONCLUSION AND FUTURE WORK 


A. CONCLUSION 

In this thesis, we have successfully developed a network mapping application for 
integration into the proposed MAVNATT system. This application provides functionality 
for network administrators to develop a network plan, visualize and verify that plan, scan 
the live network for comparison and validation, and export the network configuration for 
import and use by the MAVNATT awareness and virtualization modules. These 
functions of the mapping application provide the necessary foundation and starting point 
to virtualize an accurate replica of a local area network for use in training and security 
applications. 

The proposed network plan format allows the network administrator to succinctly 
and accurately define all entities on a network. The XML-style tagging provides for 
extensibility in the future, as more tags can be defined and implemented to increase 
the level of detail or introduce new elements to the network configuration. The decision 
to generate the plan in Microsoft Excel facilitates ease of use and portability across 
a broad range of computers due to the popularity and widespread use of the program. 
The plan is easily generated, modified and extended without reliance on complicated 
database applications or proprietary programs for data storage and manipulation. Most 
importantly, the .xlsx file format can be exported to a simple text file, allowing the 
mapping application to import and parse the network plan. 

The mapping application uses an object-oriented framework to represent the 
network architecture in a complete, detailed, and extensible manner. The relational 
interactions between objects in the network framework correctly mimic hierarchy and 
interconnectivity of devices on a LAN. This allows for future development, 
implementation, and extension to provide further functionality, detail and feature sets by 
extending the individual objects within the framework. Furthermore, this framework 
provides a foundation for use by other modules with the MAVNATT system to interact 
with and develop network-related structures. 
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The visualization feature of the mapping application is an important function that 
assists the network administrator in verifying the network, allowing for quick recognition 
of problems and pitfalls. The visual representation of the network plan after its import 
provides an opportunity to recognize potential errors in the planned configuration and 
settings. Likewise, the visualization of the live network after scanning provides an easy to 
use tool, color coded for quick reference and confirmation of actual settings compared to 
the expected values of the network plan. The visualization screens are reconfigurable, 
allowing the user to drag, rotate, and shift individual nodes in the graph to a location of 
their choice. This further facilitates ease of use, allowing network administrators to 
customize the visualization to their liking. 

In addition to the simple visualization view, the application displays log messages 
to the console throughout the mapping process. These log messages provide further detail 
on the status of the mapping effort, identifying potential errors and misconfigured 
settings in the process. When mapping is complete, the user has the option to save a 
detailed report of the current network configuration and settings as a text file. These log 
messages and configuration files provide the fine-grained detail needed for the network 
administrator to correct problems identified during the mapping and visualization 
process. 

Finally, the mapping application provides functionality to export the network in 
the GraphML file format. This file provides information about the configuration and 
settings of the network, including details of individual network entities as well as 
connections between devices. The content of the file can be easily extended, either 
manually or by making alterations to the mapping application itself. This again provides 
the necessary framework for the future addition of features including increased detail of 
network entities. This export operation is a key function, as it provides the necessary 
information required for other modules within the MAVNATT framework to import a 
complete network representation. 

We believe this mapping application provides a full-featured foundation for the 

proposed MAVNATT system. The application includes all the functionality needed to 

correctly and accurately plan, visualize, scan and export a representation of a local area 
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network. This representation can be used for analysis or for further import by another 
module in the MAVNATT system. 

B. FUTURE WORK 

This application provides the basic functionality needed to satisfy the 
requirements of the MAVNATT mapping module; however, there are areas for further 
research as well as the implementation of increased functionality. Enhancements to the 
mapping application itself can be made to increase the detail available for individual 
network entities, provide an improved feature set for the application, or to allow for 
increased flexibility within the network plan. Further work is also required to fully 
implement, test, and integrate the mapping module into the MAVNATT framework to 
provide a start-to-finish functionality of mapping, monitoring, and virtualizing a network. 

1. Increased Detail and Flexibility 

The mapping application in its current state provides a limited amount of detail 
for representing a LAN. Individual devices are identified by the MAC address and IP 
address, with the ability to store additional data such as device name, gateway router, etc. 
Future implementations can expand on this foundation to provide an increased level of 
detail and fidelity, allowing for greater depth when representing a network. Advanced 
methods such as device fingerprinting and connection-oriented data collection can be 
used to increase the level of fidelity for identification of networked devices. 

a. Device Fingerprinting 

A device fingerprinting approach would provide functionality to uniquely identify 
specific machines on the network with a higher level of fidelity. Such an approach would 
require a network administrator to generate an initial database of fingerprints, either for 
individual devices on the network, or for specific subsets of devices with particular 
services. After the initial establishment of the fingerprint database, the live network scan 
can confirm or deny the presence of a networked device via the stored identifying 
information rather than just the MAC address or IP address. 
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b. 


Connection-Oriented Data Collection 


The mapping application currently uses probing techniques to retrieve data about 
networked devices. The application sends a probe to specific addresses, eliciting an 
automatic response from the network stack of that device without actually making a 
connection. This response is then parsed for required information. A connection-oriented 
approach would allow the user to collect more in-depth information about specific 
devices. Options for initiating connections to remote devices include Secure Shell for 
routers, or the establishment of Simple Network Management Protocol relationships 
between the devices on the network. 

c. Dynamic Network Configurations 

The devised network plan format described in Chapter III, Section C, requires 
static assignment of IP addresses for all devices on the network. This format presents 
complications when mapping LANs that implement the Dynamic Host Configuration 
Protocol to automatically assign IP addresses. Such implementation is common with 
wireless networks or those that have devices connected intermittently. Future 
improvements to the mapping application could account for the dynamic nature of such 
networks. Doing so requires identifying devices on the network by features other than IP 
address alone, such as the fingerprinting method described above. Another option would 
be run a mapping application from a local host on each subnet in the LAN; however, 
further research and development is needed to correlate that data and scan results from 
multiple applications. 

2. Mapping Unknown Networks 

This implementation of the MAVNATT mapping module assumes administrator- 

level access to a LAN along with detailed prior knowledge of the configuration and 

topology of the network. There is currently no functionality for mapping an unknown 

network from an unknown starting point. Further research and extension of the 

application could potentially address this issue. Mapping a network from an unknown 

starting point presents certain difficulties, and in many cases a topology cannot be 

confirmed, only estimated. Extension of the mapping application to include the 
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functionality to scan unknown networks could potentially lead to a tool to determine 
information about adversarial networks. 

a. Bounded Search Requirement 

One difficulty when mapping an unknown network is the question of where to 
stop. If a LAN consists of several subnets, then any effort to map the entire LAN must 
necessarily send traffic across broadcast domains to reach devices separated by routers. 
Without prior knowledge of the subnet and IP address allocation schemes, automated 
mapping efforts could easily extend search areas to those beyond the LAN in question. 
Methods to remedy this problem include enforcing a bounded search constraint by 
limiting the hop count of probes from the source device, and artificially making 
inferences about the subnet to be search. In either case, it is impossible to concretely 
verify that the complete composition of a LAN has been discovered without at least some 
prior knowledge of that LAN. Future research could investigate the limitations and 
accuracy of an unbounded search in order to determine whether an automated application 
is a viable option for mapping completely unknown networks. 

b. Connection Information Discovery 

The automatic discovery of device-to-device connection information within a 
network represents a significant challenge. The implementation of the mapping 
application in this thesis assumes that a planned connection is correct if both endpoints of 
that connection have been confirmed; however, the actual physical connection topology 
may deviate from the expected planned configuration. A subnet and its broadcast domain 
may actually be subdivided by intermediate devices (e.g., hubs and switches). These 
devices forward traffic on the data link layer and are virtually transparent on the network 
layer; however, they also contain valuable information about the network topology via 
the internal switch table which contains a MAC address listing of all connected devices. 
Discovery of these devices and their corresponding connections would require additional 
techniques for monitoring physical layer and data link layer traffic in conjunction with 
network layer traffic, but will yield a much more robust picture of the network topology. 
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c. Point of Collection 

The amount and type of traffic available for analysis varies greatly with the point 
of collection on the network, of which there are several options. Data collection can be 
conducted from a host computer connected to the subnet, which is the method employed 
by the mapping application in this thesis. Alternatively, a wiretap device can be used to 
passively collect traffic from a point within the network. Both options allow for 
collection and analysis of local network traffic, but both require physical access to the 
network. In certain scenarios, such as mapping an adversarial network, physical access is 
not a viable option. Mapping from within a network is fundamentally different from 
mapping from an external position. Efforts to map an external network can be constrained 
by several factors including network address translation, firewalls, and security policies 
which may hinder mapping efforts using typical scanning techniques. 

3. Integration, Testing, and Utilization 

As of publication of this thesis, the MAVNATT system has not been fully 
implemented or integrated. In addition to the mapping application proposed here, a 
solution for the virtualization module has been proposed by Naval Postgraduate School 
student, Erik Bemdt [22]. Eurther research on the implementation of the proposed 
awareness module, as well as integration of the three modules into the overall 
MAVNATT framework, is required. 

a. MAVNATT Awareness Module Development 

The goal of the proposed awareness module is to monitor a live network and 
provide the network administrator with real-time updates of changes to the status of the 
network. This can be accomplished by using the network framework described in Chapter 
III, Section B, to accurately represent the live network in its current state. An application 
to passively monitor network traffic can compare information found in packet headers 
and payloads to that of the expected values of the mapped network. This functionality is 
similar to that of the mapping application; an awareness module might be implemented 
by extending the functionality of the mapping application to provide a periodic or 
continuous feedback loop. 
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b. Module Integration into the MAVNATT Framework 

Further research is required to integrate the mapping module into the proposed 
MAVNATT framework and to conduct a complete process of replicating a live network 
starting from a network plan. The network plan used as input to the mapping application 
and the file formats available for export have been carefully developed to allow for 
portability and extensibility. In particular, the GraphML file format contains all required 
information to represent the network to a sufficient level of detail to create a virtualized 
replica of that network. In theory, the awareness and virtualization modules can import 
the GraphML file generated by the mapping application; however, further refinements 
may be required to ensure compatibility and test functionality. 

c. MAVNATT Testing 

Upon completion of development and integration of all MAVNATT modules, 
research is required to test functionality and limitations of the overall system. The desired 
end state is that a user can generate and import a network plan, scan the live network to 
compare findings, monitor the network based on those finding, and create a virtualized 
replica of the network. Testing is required to determine limitations on the type and 
number of devices that can be virtualized and any potential errors when virtualizing 
planned networks. 

d. Utilization of the MAVNATT System 

The initially proposed purpose of the MAVNATT system was to allow network 
administrators a training tool for evaluating their local network without fear of disrupting 
the live network stability. The functionality of MAVNATT to plan and virtualize 
practically any network configuration provides the opportunity to use it in scenarios other 
than for network administrator training, such as those employed on cyber ranges. A cyber 
range is a fully functional network environment used for testing and training purposes 
that extend beyond the scope of general network administration. Typical cyber range 
usage scenarios include: 

• Penetration testing to determine vulnerabilities in the network 
configuration and how to defend against exploitation. 
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• Simulation of effects of malware or viruses on the network. 

• Training for the offensive exploitation of network vulnerabilities. 

Cyber ranges are generally set up as physical networks, limiting their availability 
and scale of the network topology. The ability to dynamically configure and virtualize a 
network with the MAVNATT system could potentially provide a new method for 
employing cyber ranges. Extended cyber ranges could also be created by connecting two 
or more virtualized networks, or by connecting a virtualized network to a physical cyber 
range. 
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APPENDIX A. NETWORK ERAMEWORK UML DIAGRAM 
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APPENDIX B. NETWORK PLAN CSV EILE 


<NETWORKS>,,,,,, 

Subnet ID,Notes,,,,, 

192.168.0.0/26,,,,, , 

192.168.0.64/26,,,,,, 

192.168.0.208/30,,,, , , 

</NETWORKS>,,,,,, 

<ROUTERS>,,,,,, 

Router Name,Interface Name,Interface MAC,Interface IP,Next Hop (IP or switch name),, 

R2,faO/1,00:IB:D4:EF:5C:89,192.168.0.209,192.168.0.210,, 

R2,fa0/0/0,00:lB:D4:EF:50:88,192.168.0.1,Switch 1, , 

R3,faO/1,00:IB:54:A9:6D:C9,192.168.0.210,192.168.0.209,, 

R3,faO/0/0,58:8D:09:76:E9:F4,192.168.0.65,Switch 2,, 

</ROUTERS>,,,, , , 

<HOSTS AND CLIENT DEVICES>,,,,,, 

Host Name,Interface Name,Interface MAC,Interface IP,Next Hop (IP or switch name),Gateway Address,Device Type 

Client2,ethO,C8:1F:66:07:0F:1D,192.168.0.20,Switch 1,192.168.0.1,COMPUTER 

Clients,ethO,C8:1F:66:0F:D6:B9,192.168.0.30,Switch 1,192.168.0.1,COMPUTER 

Clients,ethO,D8:CB:8A:60:4B:E0,192.168.0.80,Switch 2,192.168.0.65,COMPUTER 

Clients,ethO,C8:1F:66:07:10:7E,192.168.0.90,Switch 2,192.168.0.65,COMPUTER 

Printer2,ethernet,00:15:99:D5:5D:34,192.168.0.100,Switch 2,192.168.0.65,PRINTER 

</HOSTS AND CLIENT DEVICES>, , , , , , 

<LAYER 2 SWITCHES>, , , , , , 

Switch Name,Number of connections,,,,. 

Switch 1,3,,,,, 

Switch 2,4,,,,, 

</LAYER 2 SWITCHES>, , , , , , 

<IMAGE FILES>, , , , , , 

Platform Name,Operating System Name,Image File Location,,,, 

R2,lOS,C:\Users\M4600\Desktop\MAVNATT\REPO\router2.vdi,,,, 

R3,lOS,C:\Users\M4600\Desktop\MAVNATT\REPO\router3.vdi,,,, 

Cllent2,Ubuntu,C:\Users\M4 60 0\Desktop\MAVNATT\REPO\Ubuntu_l.vdi,,,, 

Clients,Windows 10,C:\Users\M4 60 0\Desktop\MAVNATT\REPO\Windows10_1.vdi,,,, 

Clients,Ubuntu,C:\Users\M4 60 0\Desktop\MAVNATT\REPO\Ubuntu_l.vdi,,,, 

Clients,Ubuntu,C:\Users\M4 60 0\Desktop\MAVNATT\REPO\Ubuntu_l.vdi,,,, 

</IMAGE FILES>,,,,,, 
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APPENDIX C. LIVE NETWORK DETAILS EILE 


Results of live network scan on Thu Apr 07 09:05:06 PDT 2016 
==============NETWORK DEVICES============== 


Name: 

Type: 

Operating System: 
Status: 

Interface: 

IPv4 Address: 
MAC Address: 
Status: 


R2 

ROUTER 

lOS 

CONEIRMED 

faO/1 

192.168.0.209 

00:1B:D4:EE:5C:89 

CONEIRMED 


Interface: 

IPv4 Address: 
MAC Address: 
Status: 


faO/0/0 
192.168.0.1 
00:1B:D4:EE:5C:88 
CONEIRMED 


Name: 

Type: 

Operating System: 
Status: 

Interface: 

IPv4 Address: 
MAC Address: 
Status: 

Interface: 

IPv4 Address: 
MAC Address: 
Status: 

Name: 

Type: 

Operating System: 
Status: 


R3 

ROUTER 

lOS 

CONEIRMED 

faO/0/0 

192.168.0.65 

58:8D:09:76:E9:E4 

CONEIRMED 

faO/1 

192.168.0.210 

00:IB:54:A9:6D:C9 

CONEIRMED 

Client2 
COMPUTER 
Linux 3.2 - 4.4 
CONEIRMED 


Interface: 

IPv4 Address: 
MAC Address: 
Status: 


ethO 

192.168.0.20 

C8:IE:66:07:OE:ID 

CONEIRMED 
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Name: 

Type: 

Operating System: 
Status: 

Interface: 

IPv4 Address: 
MAC Address: 
Status: 

Name: 

Type: 

Operating System: 
Status: 

Interface: 

IPv4 Address: 
MAC Address: 
Status: 

Name: 

Type: 

Operating System: 
Status: 

Interface: 

IPv4 Address: 
MAC Address: 
Status: 

Name: 

Type: 

Operating System: 
Status: 


DESKTOP-CLIENTS 
COMPUTER 
Windows 10 
CONEIRMED 

ethl 

192.168.0.30 

C8:IE:66:0E:D6:B9 

CONEIRMED 

Clients 
COMPUTER 
Linux 3.2 - 4.4 
CONEIRMED 

ethO 

192.168.0.80 

D8:CB:8A:60:4B:E0 

CONEIRMED 

Client 6 
COMPUTER 
Linux 3.2 - 4.4 
CONEIRMED 

ethO 

192.168.0.90 

C8:IE:66:07:10:7E 

CONEIRMED 

Printer2 

PRINTER 

CONEIRMED 


Interface: 

IPv4 Address: 
MAC Address: 
Status: 

Name: 

Type: 

Connections: 

Name: 

Type: 

Connections: 


ethernet 

192.168.0.100 

00:15:99:D5:5D:34 

CONEIRMED 

Switch 1 
SWITCH 

3 

Switch 2 
SWITCH 

4 
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^NETWORK CONNECTIONS 


<192.168 
<192.168 
<192.168 
<192.168 
<192.168 
<192.168 
<192.168 
<192.168 


0.210 <—> 192.168.0.209> : CONEIRMED 
0.20 <—> Switch 1> : CONEIRMED 
0.30 <—> Switch 1> : CONFIRMED 
0.1 <—> Switch 1> : CONFIRMED 
0.100 <—> Switch 2> : CONFIRMED 


0 . 90 

<- 

-> 

Switch 

2> 

CONFIRMED 

0.80 

<- 

-> 

Switch 

2> 

CONFIRMED 

0 . 65 

<- 

-> 

Switch 

2> 

CONFIRMED 
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APPENDIX D. CONTROL CONFIGURATION NETWORK PLAN 


<NETWORKS> 

Subnet ID 

Notes 

192.168.0.0/26 







192.168.0.64/26 







192.168.0.128/30 







192.168.0.200/30 







192.168.0.204/30 







192.168.0.208/30 







192.168.0.212/30 







192.168.0.216/30 







</NETWORKS> 

<ROUTERS> 

Router Name 

Interface Name 

Interface M21C 

Interface IP 

Next Hop (IP or switch name) 

R1 

faO/0 

00:15:63:40:83:80 

192.168.0.201 

192.168.0.202 



R1 

faO/1 

00:15:63:40:83:81 

192.168.0.217 

192.168.0.218 



R1 

faO/0/0 

54:75:D0:7C:70:9F 

192.168.0.129 

192.168.0.130 



R2 

faO/0 

00:1B:D4:EF:5C:88 

192.168.0.1 

Switch 1 



R2 

faO/1 

00:1B:D4:EF:5C:89 

192.168.0.209 

192.168.0.210 



R2 

faO/0/0 

EF:5F:B9:58:8B:74 

192.168.0.206 

192.168.0.205 



R3 

faO/0 

00:IB:54:A9:6D:C8 

192.168.0.202 

192.168.0.201 



R3 

faO/1 

00:IB:54:A9:6D:C9 

192.168.0.210 

192.168.0.209 



R3 

faO/0/0 

58:8D:09:76:E9:F4 

192.168.0.65 

Switch 2 



R4 

faO/0 

00:18:73:10:27:00 

192.168.0.213 

192.168.0.214 



R4 

faO/1 

00:18:73:10:27:01 

192.168.0.218 

192.168.0.217 



R5 

faO/0 

00:17:59:71:34:BO 

192.168.0.205 

192.168.0.206 



R5 

faO/1 

00:17:59:71:34:B1 

192.168.0.214 

192.168.0.213 



</ROUTERS> 



<HOSTS 

AND CLIENT DEVICES> 



Host Name 

Interface Name 

Interface MAC 

Interface IP 

Next Hop (IP or switch name) 

Gateway Address 

Device Type 

Clientl 

ethO 

C8:1F:66:07:12:05 

192.168.0.10 

Switch 1 

192.168.0.1 

COMPUTER 

Client2 

ethO 

C8:lF:66:07:0F:lO 

192.168.0.20 

Switch 1 

192.168.0.1 

COMPUTER 

Client3 

ethO 

C8 : IF:66:0F:O6:B9 

192.168.0.30 

Switch 1 

192.168.0.1 

COMPUTER 

Client4 

ethO 

08:CB:8A:60:4C:3B 

192.168.0.70 

Switch 2 

192.168.0.65 

COMPUTER 

Clients 

ethO 

08:CB:8A:60:4B:E0 

192.168.0.80 

Switch 2 

192.168.0.65 

COMPUTER 

Client6 

ethO 

C8:1F:66:07:10:7E 

192.168.0.90 

Switch 2 

192.168.0.65 

COMPUTER 

Printer2 


00:15:99:05:50:34 

192.168.0.100 

Switch 2 

192.168.0.65 

PRINTER 

Web Server 

ethO 

00:1A:A0:56:6C:B2 

192.168.0.130 

192.168.0.129 

192.168.0.129 

COMPUTER 



</HOSTS 

AND CLIENT DEVICES> 



<IAYER 2 SWITCHES> 

Switch Name 

Number of connections 


Switch 1 

4 


Switch 2 

5 


</LAYER 2 SWITCHES> 


71 

























THIS PAGE INTENTIONALLY LEET BLANK 


72 



APPENDIX E. INVALID NETWORK PLAN 


<NETWORKS> 

Stibnet ID 

Notes 

192.168.0.0/26 







192.168.0.64/26 







192.168.0.128/30 







192.168.0.200/30 







192.168.0.204/30 







192.168.0.208/30 







192.168.0.2122/30 







192.168.0.216/30 







</NETWORKS > 

<ROUTERS> 

Router Name 

Interface Name 

Interface MAC 

Interface IP 

Next Hop (IP or switch name) 

R1 

faO/0 

00:15:63:40:83:80 

192.168.0.201 

192.168.0.202 



R1 

faO/1 

00:15:63:40:83:81 

192.168.0.217 

192.168.0.218 



R1 

faO/0/0 

54:75:D0:7C:70:9F 

192.168.0.129 

192.168.0.130 



R2 

faO/0 

E0:5F:B9:58:8B:74 

192.168.0.1 

Switch 1 



R2 

faO/1 

00:1B:D4:EF:5C:89 

192.168.0.209 

192.168.0.210 



R2 

faO/0/0 

00:1B:D4:EF:5C:88 

192.168.0.206 

192.168.0.205 



R3 

faO/0 

00:1B:54:A9:6D:C8 

192.168.0.202 

192.168.0.201 



R3 

faO/1 

00:1B:54:A9:6D:C9 

192.168.0.210 

192.168.0.211 



R3 

faO/0/0 

58:8D:09:76:E9:F4 

192.168.0.65 

Switch 3 



R4 

faO/0 

00:18:73:10:27:00 

192.168.0.213 

192.168.0.214 



R4 

faO/1 

00:18:73:10:27:01 

192.168.0.218 

192.168.0.217 



R5 

faO/0 

00:17:59:71:34:B0 

192.168.0.205 

192.168.0.206 



R5 

faO/1 

00:17:59:71:34:B1 

192.168.0.214 

192.168.0.213 



</ROUTERS> 



<HOSTS 

AND CLIENT DEVICES> 


Host Name 

Interface Name 

Interface MAC 

Interface IP 

Next Hop (IP or switch name) 

Gateway Address 

Device Type 

Clientl 

ethO 

C8:1F:66:07:12:05 

192.168.0.10 

Switch 1 

192.168.0.1 

COMPUTER 

Client2 

ethO 

C8:lF:66:07:0F:lO 

192.168.0.20 

Switch 1 

192.168.0.1 

COMPUTER 

Client3 

ethO 

C8:lF:66:0F:O6:B9 

192.168.0.30 

Switch 1 

192.168.0.1 

COMPUTER 

Client4 

ethO 

O8:CB:8A:60:4C:3B 

192.168.0.70 

Switch 2 

192.168.0.65 

COMPUTER 

Clients 

ethO 

O8:CB:8A:60:4B:E0 

192.168.0.80 

Switch 2 

192.168.0.65 

COMPUTER 

Client 6 

ethO 

C8:1F:66:07:10:7E 

192.168.0.90 

Switch 2 

192.168.0.65 

COMPUTER 

Printer2 


00:15:99:05:50:34 

192.168.0.100 

Switch 2 

192.168.0.65 

PRINTER 

Web Server 

ethO 

00:1A:A0:56:6C:B2 

192.168.0.130 

192.168.0.129 

192.168.0.129 

COMPUTER 



</HOSTS 

AND CLIENT DEVICES> 


<LAYER 2 SWITCHES> 

Switch Name 

Number of connections 


Switch 1 

4 






Switch 2 

5 






</LAYER 2 SWITCHES> 
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APPENDIX F. INCORRECT DETAILS NETWORK PLAN 


<NETWORKS> 

Subnet ID 

Notes 

192.168.0.0/26 







192.168.0.64/26 







192.168.0.128/30 







192.168.0.200/30 







192.168.0.204/30 







192.168.0.208/30 







192.168.0.212/30 







192.168.0.216/30 







</NETWORKS> 

<ROUTERS> 

Router Name 

Interface Name 

Interface MAC 

Interface IP 

Next Hop (IP or switch name) 

R1 

faO/0 

00:15:63:40:83:80 

192.168.0.201 

192.168.0.202 



R1 

faO/1 

00:15:63:40:83:81 

192.168.0.217 

192.168.0.218 



R1 

faO/0/0 

54:75:D0:7C:70:9F 

192.168.0.129 

192.168.0.130 



R2 

faO/0 

E0:5F:B9:58:8B:74 

192.168.0.1 

Switch 1 



R2 

faO/1 

00:1B:D4:EF:5C:89 

192.168.0.209 

192.168.0.210 



R2 

faO/0 

00:1B:D4:EF:5C:88 

192.168.0.206 

192.168.0.205 



R3 

faO/0/0 

00:IB:54:A9:6D:C8 

192.168.0.202 

192.168.0.201 



R3 

faO/1 

00:IB:54:A9:6D:C9 

192.168.0.210 

192.168.0.211 



R3 

faO/0/0 

58:8D:09:76:E9:F4 

192.168.0.65 

Switch 2 



R4 

faO/0 

00:18:73:10:27:00 

192.168.0.213 

192.168.0.214 



R4 

faO/1 

00:18:73:10:27:01 

192.168.0.218 

192.168.0.217 



R5 

faO/0 

00:17:59:71:34:B0 

192.168.0.205 

192.168.0.206 



R5 

faO/1 

00:17:59:71:34:B1 

192.168.0.214 

192.168.0.213 



</ROOTERS> 

<HOSTS AND CLIENT DEVICES> 

Host Name 

Interface Name 

Interface MAC 

Interface IP 

Next Hop (IP or switch name) 

Gateway Address 

Device Type 

Clientl 

ethO 

C8:1F:66:07:12:05 

192.168.0.10 

Switch 1 

192.168.0.1 

COMPUTER 

Client2 

ethO 

C8:IF:66:07:OF:IE 

192.168.0.20 

Switch 1 

192.168.0.1 

COMPUTER 

Client3 

ethO 

C8:IF:66:0F:O6:B9 

192.168.0.33 

Switch 1 

192.168.0.1 

COMPUTER 

Client4 

ethO 

D8:CB:8A:60:4C:3B 

192.168.0.70 

Switch 2 

192.168.0.65 

COMPUTER 

Clients 

ethO 

D8:CB:8A:60:4B:E0 

192.168.1.88 

Switch 2 

192.168.0.65 

COMPUTER 

Client6 

ethO 

C8:1F:66:07:10:7E 

192.168.0.90 

Switch 2 

192.168.0.65 

COMPUTER 

Printer2 


00 :15:99:D5:5D:33 

192.168.0.100 

Switch 2 

192.168.0.65 

PRINTER 

Web Server 

ethO 

00:lA:AO:56:6C:B2 

192.168.0.130 

192.168.0.129 

192.168.0.129 

COMPUTER 

</HOSTS AND CLIENT DEVICES> 

<LAYER 2 SWITCHES> 

Switch Name 

Number of connections 


Switch 1 

4 






Switch 2 

5 






</LAYER 2 SWITCHES> 
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APPENDIX G. INVALID CONFIGURATION NETWORK PLAN 


<NETWORKS> 

Subnet ID 

Notes 

192.168.0.0/26 






192.168.0.64/26 






192.168.0.128/30 






192.168.0.200/30 






192.168.0.204/30 






192.168.0.208/29 






192.168.0.216/30 






</NETWORKS> 

<ROUTERS> 

Router Name 

Interface Name 

Interface MA.C 

Interface IP 

Next Hop (IP or switch name) 

R1 

faO/0 

00:15:63:40:83:80 

192.168.0.201 

192.168.0.202 


R1 

faO/l 

00:15:63:40:33:81 

192.168.0.217 

192.168.0.218 


R1 

faO/0/0 

54:75:D0:7C:70:9F 

192.168.0.129 

192.168.0.130 


R2 

faO/0 

00 : 1B:D4:EF:5C:88 

192.168.0.1 

Switch 1 


R2 

faO/1 

00 : 1B:D4:EF:5C:89 

192.168.0.209 

192.168.0.210 


R2 

faO/0/0 

EO:5F:B9:58:8B:74 

192.168.0.206 

192.168.0.205 


R3 

faO/O 

00:IB:54:A9:6D:C8 

192.168.0.202 

192.168.0.201 


R3 

faO/1 

00:IB:54:A9:6D:C9 

192.168.0.210 

192.168.0.209 


R3 

faO/0/0 

58:8D:09:76:E9:F4 

192.168.0.65 

Switch 2 


R4 

faO/0 

00:18:73:10:27:00 

192.168.0.213 

192.168.0.214 


R4 

faO/1 

00:18:73:10:27:01 

192.168.0.218 

192.168.0.217 


R5 

faO/0 

00 : 17:59:71:34:B0 

192.168.0.205 

192.168.0.206 


R5 

faO/1 

00 : 17:59:71:34:B1 

192.168.0.214 

192.168.0.213 


</ROOTERS> 



<HOSTS 

AND CLIENT DEVICES> 


Host Name 

Interface Name 

Interface MA.C 

Interface IP 

Next Hop (IP or switch name) Gateway Address 

Device Type 

Clientl 

ethO 

C8:1F:66:07:12:05 

192.168.0.10 

Switch 1 192.168.0.1 

COMPUTER 

Client2 

ethO 

C8:lF:66:07:0F:lO 

192.168.0.20 

Switch 1 192.168.0.1 

COMPUTER 

Client3 

ethO 

C8 : IF:66:0F:O6:B9 

192.168.0.30 

Switch 1 192.168.0.1 

COMPUTER 

Client4 

ethO 

08:CB:8A:60:4C:3B 

192.168.0.70 

Switch 2 192.168.0.65 

COMPUTER 

Clients 

ethO 

08 :CB:8A:60:4B:E0 

192.168.0.80 

Switch 2 192.168.0.65 

COMPUTER 

Client6 

ethO 

C8:1F:66:07:10:7E 

192.168.0.90 

Switch 2 192.168.0.65 

COMPUTER 

Printer2 


00:15:99:05:50:34 

192.168.0.100 

Switch 2 192.168.0.65 

PRINTER 

Web Server 

ethO 

00:lA:AO:56:6C:B2 

192.168.0.130 

192.168.0.129 192.168.0.129 

COMPUTER 



</HOSTS 

AND CLIENT DEVICES> 


<LAYER 2 SWITCHES> 

Switch Name 

Number of connections 


Switch 1 

4 




Switch 2 

5 




</LaYER 2 SWITCHES> 
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